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(54) Persistent programming system and method for deploying self-contained executable 
applications 



(57) The invention creates a self-contained execut- 
able application. A compiler compiles an application in- 
cluding main source code and initialization code to gen- 
erate a list of objects needed for execution of the appli- 
cation. A processing device executes the compiled ap- 



plication to cause the initialization code to load the listed 
objects as persistent objects into a single persistent 
store. The processing device then stabilizes the persist- 
ent store to create the self-contained executable appli- 
cation which appears to a user as a single executable 
file. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention is directed generally to a sys- 
tem and method using persistent programming to de- 
ploy self-contained, executable applications, and more 
specifically to a system and method for encapsulating 
an application such that it appears to a user as a single 
executable file. 

As computers become more powerful, software ap- 
plications provide more functionality and thus become 
more complex. Current mechanisms for deploying ap- 
plications are complex, typically involving installing mul- 
tiple files on the machine on which the application is de- 
ployed. Removing the application or installing a new ver- 
sion is a complex task and typically prone to errors. 

The process of installing an application involves 
physically transferring specific application components, 
ensuring the consistency of the complete set of compo- 
nents, and, perhaps, capturing the locations of the com- 
ponents for a subsequent un installation. 

Current practice normally handles physical trans- 
ferring of application components by bundling the com- 
ponents as a separate file or package and extracting 
them at the destination. This latter step involves storing 
the extracted components as individual files, and is 
done either explicitly by the extraction or under the con- 
trol of an installation program. Some programming sys- 
tems, particularly those operating on PC platforms, bun- 
dle the components into an executable program that is 
simply executed to achieve both steps. Other program- 
ming systems, such as Java, dynamically load the ap- 
plication components at run time- 
Once installed as a collection of individual files, in- 
consistencies may develop, particularly if components 
are shared between applications, or if the component 
files can be manipulated directly outside the control of 
the application. Some systems, for example, permit con- 
figuration files including user-customization data (e.g., 
screen colors) and application-state data to be manipu- 
lated outside the control of the application. Such manip- 
ulation may cause data inconsistencies. 

Other systems, such as MacOS®, manage incon- 
sistencies by collecting the code and data for an appli- 
cation into a single file. Still other systems, such as So- 
laris®, manage inconsistencies by recording dependen- 
cies between software components. 

At some point after an application has been in- 
stalled, a user may wish to remove or upgrade it. Re- 
moving applications or upgrading to a new version re- 
quires knowing the location of the component files. 
Some installation programs create an uninstall program 
at installation time to facilitate removal of the applica- 
tion. 

None of the conventional systems, however, pro- 
vides complete application consistency or persistence 
of the application's components. Therefore, a need ex- 
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ists for maintaining the consistency of the application 
components while assisting installation, manipulation, 
and removal of the application. 

s SUMMARY OF THE INVENTION 

The present invention addresses this need by en- 
capsulating the application components as persistent 
objects in a single, executable persistent store using a 

10 persistent programming system. 

In accordance with the purpose of the invention as 
embodied and broadly described herein, the present in- 
vention includes an encapsulation system and method 
that create a self-contained executable application. A 

is compiler compiles an application including main source 
code and initialization code to generate a list of objects 
needed for execution of the application. A processing 
device executes the compiled application to cause the 
initialization code to load the listed objects as persistent 

20 objects into a single persistent store. The processing de- 
vice stabilizes the persistent store to create the self-con- 
tained executable application which appears to a user 
as a single executable file. 

25 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporat- 
ed in and constitute a part of this specification, illustrate 
an embodiment of the invention and, together with the 
30 description, serve to explain the objects, advantages 
and principles of the invention. In the drawings, 

Fig. 1 is a block diagram of a computer implement- 
ing the encapsulation method of the present inven- 
ts tion; 

Fig. 2 shows the contents of the memory shown in 

Fig. 1; 

Fig. 3 shows the contents of a persistent store 
shown in Fig. 2; and 
40 Fig. 4 is a flowchart illustrating a preferred imple- 
mentation of the encapsulation method of the 
present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 



The following detailed description of the invention 
refers to the accompanying drawings that illustrate pre- 
ferred embodiments of the invention. Other embodi- 

so ments are possible and changes may be made to the 
embodiments without departing from the spirit and 
scope of the invention. The following detailed descrip- 
tion is, therefore, not to be considered as limiting the 
invention. The scope of the invention is defined only by 

55 the appended claims. 

The present invention encapsulates an applica- 
tion's components, including all the code, configuration 
data, resources, etc., in a single persistent store, such 
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that the application appears to a user as a single exe- 
cutable file. 

Fig. 1 shows a computer 1000 implementing the 
present invention. Computer 1000 includes processor 
1010, memory 1020, and input/output 1030. Processor s 
1010 may be any type of processor that executes soft- 
ware applications. Processor 1010 operates using a 
persistent programming language, preferably the Per- 
sistent Java (PJava) programming language. PJava, an 
offspring of Java, provides orthogonal persistence for 
Java, mean ing that all objects, no matter what their type, 
have equal rights to persistence including, longevity and 
brevity. PJava is described in an article by Michael J. 
Jordan entitled "Early Experiences with Persistent Java, 
" First International Workshop on Persistence for Java, 
September 16-18, 1996, which is hereby incorporated 
by reference. 

Memory 1020 includes ROM, RAM, optical disks, 
etc. for storing the operating code and application soft- 
ware executed by processor 1010, and any data needed 
for their execution. Input/output 1030 includes a key- 
board, a mouse, a monitor, a modem, various disk 
drives, etc. for permitting communication between com- 
puter 1 000 and a user or another computer. 

Fig. 2 shows the contents of memory 1 020. Memory 
1 020 preferably includes operating system 201 0, one or 
more persistent stores 2020, compiler program 2030, 
and miscellaneous data and files 2040. Operating sys- 
tem 2010 controls the operation of computer 1000, and 
compiler 2030 compiles source code into object code 
as is commonly known in the art. Persistent stores 2020 
are executable self-contained applications. A persistent 
store, according to the present invention, is a single, pro- 
tected entity containing persistently bound data and 
code of the application. 

Fig. 3 shows persistent store 2020 in more detail. 
Persistent store 2020 preferably includes initialization 
code 3010 and compiled source code 3020. Compiled 
source code 3020 includes persistently bound code and 
data 3022 and other various resources 3024 needed for 
execution of the application. Initialization code 3010 will 
be described below with respect to Fig. 4. 

Fig. 4 is a flow chart of a procedure 4000 for encap- 
sulating an application according to this invention. En- 
capsulation procedure 4000 includes four logical groups 
of steps: compile 4100, execute 4200, configure 4300, 
and stabilize 4400. 

Encapsulation procedure 4000 begins with compil- 
er 2030 compiling the application [step 4110]. Prefera- 
bly, compiler 2030, such as a Java compiler, generates 
a list of objects (e.g., code, data, resources, etc. ) need- 
ed to run the application [step 41 20]. 

From the perspective of determining the set of 
needed objects, applications fall into one of three cate- 
gories: (1 ) those for which the set of needed objects can 
be determined statically by examining the source code; 
(2) those which dynamically choose the needed objects 
from a fixed, statically determined set at run time; and 



(3) a variant of the second category in which the set of 
loadable objects is open-ended and the objects have dy- 
namically generated names. 

The vast majority of applications fall into the first cat- 
egory and a small number fall into the second. An ex- 
ample of the third category is a highly integrated pro- 
gram development environment that compiles and 
loads newly created source code into the same virtual 
machine as the environment itself. 

Precisely determining the set of objects in the first 
category requires an analysis similar to that performed 
by a Java compiler. The Java compiler records the rel- 
evant information in an object file generated by the com- 
piler. The set of objects reachable from one or more root 
objects can be determined at application build time by 
a transitive closure process. The Java compiler's ability 
to specify other objects as roots supports those appli- 
cations that generate object names dynamically, such 
as those applications in the third category. 

In an alternative embodiment, only root objects, typ- 
ically the ones containing a main method of the applica- 
tion, are identified, and instances of these objects are 
created and made persistent in an application initializa- 
tion mode (to be discussed below). 

After generating the list of needed objects, proces- 
sor 1010 launches the compiled application into the in- 
itialization mode [step 4210] discussed above. In the 
preferred embodiment, the initialization code is sepa- 
rate from the main source code, as shown in Fig. 3. Up- 
on execution of the application, processor 1010 invokes 
the appropriate code depending on the mode of opera- 
tion. Alternatively, the initialization mode may be 
launched by a command-line or screen dialog argu- 
ment. This latter method, however, does not provide the 
clean separation of the initialization code from the main 
source code as in the former method. 

Executing the initialization code forces all needed 
objects into one of the persistent stores 2020 [step 
4220]. In the alternative embodiment discussed above, 
where an instance of a root object is created and made 
persistent in the application initialization mode, proces- 
sor 1010 exercises a feature of PJava that forces all ob- 
jects referenced by the identified root objects to be tran- 
sitively loaded. 

After all the needed objects have been loaded into 
persistent store 2020, the application may be config- 
ured. For example, a user may customize the applica- 
tion [step 4310] via a graphic user interface (GUI). Cus- 
tomization might include changing the screen colors. 

Additionally, the user might associate one or more 
security managers with the application, a feature per- 
mitted by PJava. The security manager permanently 
controls the kinds of access users are permitted. The 
configuration data need not include only customization 
data or security managers, but may also include appli- 
cation state data for use in recovery upon a restart. 

Processor 1010 loads this configuration data into 
persistent store 2020 as a persistent object [step 4330].. 
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Since the configuration data is persistently stored in per- 
sistent store 2020, the application controls all access to 
it, thereby eliminating any inconsistency between the 
configuration data and the code that manipulated it. 

After loading the needed objects and the configura- 
tion data into persistent store 2020, processor 1010 sta- 
bilizes persistent store 2020, using the stabilization fea- 
ture of PJava which atomically commits the objects to 
the store [step 4410]. Processor 1010 then verifies and 
optimizes the objects in persistent store 2020 [step 
4420]. The persistent store should finally be given a 
name indicative of the application [step 4430] to facili- 
tate identification by a user. The application resides in 
a single, protected, executable entity and appears to the 
user as an ordinary executable file. 

The present invention has the following advantages 
over conventional systems: 

(1) The application objects cannot become incon- 
sistent because all the objects (including both code 
and data) are persistently stored in a single store. 
Furthermore, because the configuration data is also 
contained in this single store, as PJava objects, it 
cannot become inconsistent with the code that ma- 
nipulated it. 

(2) Locating the objects is easy because all of the 
objects are persistently bound and physically locat- 
ed in the same store. 

(3) Removing the application entails simply deleting 
the store. A new version of the application may be 
deployed either by completely replacing the existing 
store, or by applying an evolution tool to the store. 
Because Java provides full type information for all 
objects, the code may be incrementally updated 
and the configuration data may be reliably and eas- 
ily migrated. 

The foregoing description of preferred embodi- 
ments of the present invention has been presented for 
purposes of illustration and description. It is not intended 
to be exhaustive or to limit the invention to the precise 
form disclosed, and modifications and variations are 
possible in light of the above teachings or may be ac- 
quired from practice of the invention. For example, the 
computer executing the encapsulation method of the 
present invention need not operate using the PJava pro- 
gramming language, but may alternatively operate us- 
ing another persistent programming language. The 
scope of the invention is defined by the claims and their 
equivalents. 

Claims 

1. A method of creating a self-contained executable 
application comprising the steps of: 

compiling an application including main source 



code and initialization code to generate a list of 
objects needed for execution of the application; 
executing the compiled application to cause the 
initialization code to load the listed objects as 
s persistent objects into a single persistent store; 

and 

stabilizing the persistent store to create the 
self-contained executable application. 

10 2. The method of claim 1 , further comprising the step 
of 

configuring the application by permitting a us- 
er to enter customization data to customize the ap- 
plication. 

15 

3. The method of claim 2, wherein the configuring step 
includes the substep of 

associating a security manager to the appli- 
cation. 

20 

4. The method of claim 3, wherein the configuring step 
further includes the substep of 

loading the customization data and security 
manager as persistent objects into the persistent 
25 store. 

5. The method of claim 2, wherein the configuring step 
includes the substep of 

loading the customization data as persistent 
30 objects into the persistent store. 

6. The method of claim 1 , wherein the stabilizing step 
comprises the substeps of 

35 atomically committing the listed objects to the 

persistent store; and 

verifying that all the objects are persistently 
stored in the persistent store. 

40 7. A computer readable medium configured to store 
instructions to create a self-contained executable 
application, the instructions being capable of caus- 
ing a computer to perform the steps of: 

45 generating a list of objects needed for execu- 

tion of an application including initialization 
code and main source code; 
executing the initialization code to load the list- 
ed objects as persistent objects into a single 

so persistent store; and 

stabilizing the persistent store to create the 
self-contained executable application. 

8. A system to create a self-contained executable ap- 
55 plication comprising: 

a compiler configured to compile an application 
including initialization code, and main source 
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code and to generate a list of objects needed 
for execution of the application; 
a memory device configured to store a persist- 
ent store; 

a processing device connected to the compiler 
and the memory device and configured to exe- 
cute the initialization code to load the listed ob- 
jects as persistent objects into the persistent 
store, and to stabilize the persistent store to 
create the self-contained executable applica- 
tion. 

9. A self-contained, computer executable application 
stored on a storage medium comprising: 

persistent code objects comprising all code 
needed for execution of the application; 
persistent data objects comprising all data 
needed for execution of the application, the 
persistent data objects being linked to the per- 
sistent code objects and being configured to be 
executed by respective ones of the persistent 
code objects: and 

persistent configuration data objects config- 
ured to record a state of the application; 
said persistent code objects, said persistent 
data objects, and said persistent configuration 
data objects being stored in a single persistent 
executable file on said storage medium. 

1 0. The method of claim 1 , further comprising the steps 
of 

associating a security manager to the applica- 
tion; and 

loading the security manager as a persistent 
object into the persistent store. 

1 1 . The method of claim 1 , further comprising the steps 
of 

recording a state of the application; and 
loading the application state as a persistent ob- 
ject into the persistent store. 

12. The computer readable medium of claim 7, wherein 
the instructions further be ing capable of causing the 
computer to perform the step of 

configuring the application by permitting a us- 
er to enter customization data to customize the ap- 
plication. 

1 3. The computer readable medium of claim 1 2, where- 
in the configuring step comprises the substep of 

associating a security manager to the appli- 
cation. 

1 4. The computer readable medium of claim 1 3, where- 



in the configuring step further comprises the sub- 
step of 

loading the customization data and the secu- 
rity manager as persistent objects into the persist- 
s ent store. 

1 5. The computer readable medium of claim 1 2, where- 
in the configuring step comprises the substep of 

loading the customization data as persistent 
io objects into the persistent store. 

1 6. The computer readable medium of claim 7, wherein 
the stabilizing step comprises the substeps of 

is atomically committing the listed objects to the 

persistent store; and 

verifying that all the objects are persistently 
stored in the persistent store. 

20 17. The computer readable medium of claim 7, wherein 
the instructions further being capable of causing the 
computer to perform the steps of 

associating a security manager to the applica- 
25 tion; and 

loading the security manager as a persistent 
object into the persistent store. 

1 8. The computer readable medium of claim 7, wherein 
30 the instructions further being capable of causing the 

computer to perform the steps of 

recording a state of the application; and 
loading the application state as a persistent ob- 
35 ject into the persistent store. 

19. The system of claim 8, further comprising 

a configuration device configured to permit a 
user to enter customization data to customize the 
40 application. 

20. The system of claim 19, wherein the configuration 
device includes 

an association device configured to associate 
45 a security manager to the application. 

21. The system of claim 20, wherein the configuration 
device comprises 

a loading device configured to load the cus- 
50 tomization data and the security manager as per- 
sistent objects into the persistent store. 

22. The system of claim 1 9, wherein the configuration 
device comprises 

55 a loading device configured to load the cus- 

tomization data as persistent objects into the per- 
sistent store. 
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23. The system of claim 8, wherein the processing de- 
vice comprises 

a stabilizer configured to atomically commit 
the listed objects to the persistent store, and to ver- 
ify that all the objects are persistently stored in the 5 
persistent store. 



24. The system of claim 8, further comprising 

an association device configured to associate io 
a security manager to the application; and 
a loading device configured to load the security 
manager as a persistent object into the persist- 
ent store. 

15 

25. The system of claim 8, further comprising 

a recording device configured to record a state 
of the application; and 

a loading device configured to load the applica- 20 
tion state as a persistent object into the persist- 
ent store. 



26. The self-contained, computer executable applica- 
tion of claim 9, wherein the persistent configuration 2s 
data objects further comprise 

persistent customization data objects config- 
ured to customize the application. 



27. The self-contained, computer executable applica- 30 
tion of claim 9, wherein the persistent configuration 
data objects further include 

persistent security manager data objects con- 
figured to associate a security manager to the ap- 
plication. 3S 



40 



45 



50 



55 



EP 0 829 805 A1 



1000 

y 

COMPUTER 





1010 






y 




PROCESSOR 














INPUT/OUTPUT 








MEMORY 






1030 



1020 



FIG. 1 



7 



EP O 829 805 A1 



1020 



MEMORY 



2010 



OPERATING 
SYSTEM 



2030 



COMPILER 



2020 



PERSISTENT 
STORE 



PERSISTENT 
STORE 



PERSISTENT 
STORE 



MISCELLANEOUS DATA AND FILES 



2040 



FIG. 2 



8 



EP 0 829 805 A1 



2020 



PERSISTENT STORE 



3010 



INITIALIZATION 
CODE 



3020 



COMPILED SOURCE 
CODE 



CODE 








DATA 



CODE 




DATA 






• • • 




CODE 




DATA 





OTHER 
RESOURCES 




3022 



3024 



FIG. 3 



9 



EP 0 829 805 A1 



o 
o 
o 




10 



EP 0 829 805 A1 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 97 40 2074 



DOCUMENTS CONSIDERED TO BE RELEVANT 



;ategorv| 



Cit^iion of dccurv?nt ,v<th indication, v. -ere approcr -a;* 
re=?*ar.: passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION <Int.CI.6> 



EP 0 423 937 
* abstract + 



A (TEXAS INSTRUMENTS INC) 



page J. 
page 
page 5. 
page 8, 
page 18 



line 20 
line 11 
1 i ne 
1 i ne 

, 1 ine 



29 
19 
7 



line 26 

line 19 

line 33 

line 40 

line 25 



The preseniseaicn repon nas been drawn jp for ail claims 



!l -27 



606F9/44 



TECHNICAL FIELDS 
SEARCHED <»nt.Cl.6> 



G06F 









THE HAGUE 


18 November 1997 


Brandt, J 



CATEGORY of cited documents 

X : partic j»ar*v relevant if ta<en aton* 

Y : particular*-/ rsrevant tf ccmcwd wbd another 

c&cumsm ot me same caiegory 
A • tscnnoiogtcal ca-ikgrcjnc 
O fx>n-wntten dtscto$.ure 
P * intfermeatata document 



: *rv5C^> or pnncpi^ u^oertying ino invention 
: earit^r cat*m dccvment. &ut published or. or 

.after ;ha filing dat« 
: cscunena cil&d in the app'icaiicn 

•sccLrrwt cited for other reasons 

■ mciTW of it's* same patent family corresponding 



11 



